עורך הטקסט הצנוע הוא כלי הכרחי עבור מפתחים רבים, מעצבי אתרים, כותבים ואנשים שפשוט מחפשים דרך מהירה לרשום הערות. אבל יש אפשרויות הרבה יותר טובות מאשרnotepad.exe;אחד האהובים עלינוהואפנקס רשימות++.
עוד ב-2003, מהנדס תוכנהדון הולא היה מרוצה מעורך קוד המקור שבו השתמש לעבודה והחליט לקחת על עצמו את האתגר של יצירת משהו טוב יותר. Notepad++ הפך מאז למרכיב עיקרי של משתמשים רבים המחפשים תכונות עשירות יותר מעורך הטקסט המוגדר כברירת מחדל של מערכת ההפעלה שלך, וביצועים טובים יותר מאשר אפשרויות נפוחות יותר. תפסנו את דון כדי ללמוד על מה שהתרחש מאחורי האפליקציה.
מאיפה הגיע הרעיון ליישום? האם ניסית לפתור בעיה שחווית, או שההשראה הגיעה ממקום אחר?
החברה בה עבדתי השתמשה ב-JEXT (עורך קוד פתוח נוסף שנכתב ב-Java) ככלי ייצור. בשל הביצועים הגרועים שלו, התחלתי בחקירה על יצירת פתרון אחר (נכתב ב-C++ במקום ב-Java) בספטמבר 2003. מצאתילְעוֹרֵרובנה אב טיפוס באמצעותו. עם זאת, פתרון זה לא התקבל על ידי החברה שלי. אז הסרתי את החלק הספציפי הזה והמשכתי לפתח אותו בשעות הפנאי שלי. ב-25 בנובמבר 2003 הוא הפך זמין ב-SourceForge.
איך בחרת לאילו פלטפורמות למקד ולאיזה להתעלם או לחכות?
בהקשר שהוזכר לעיל, Windows הייתה פלטפורמת היעד. ואז הגעתי לחוויית הפיתוח בין הפלטפורמות (Windows/MacOSX/Linux Ubuntu) ארבע שנים מאוחר יותר (2007).
עם הרבה בקשות להעברת Notepad++ ל-MacOSX ולינוקס, כן שקלתי להעביר את הפרויקט לשתי פלטפורמות אחרות באמצעותwxWidget. היה צורך לוותר על רעיון זה עקב שימוש רב ב-API של Win32.
אבל זה לא אומר ש-Notepad++ לעולם לא יהיה יישום חוצה פלטפורמות. אנו שוקלים שינוי חשוב בטווח הבינוני, כדי להכין את הדיווח בטווח הארוך.
לאנשים יש הרבה אפשרויות בבחירת עורכי טקסט וקוד; אילו תכונות היו חשובות עבורך בעת עיצוב Notepad++? במה רצית שזה יהיה שונה מעורכים אחרים?
הביצוע. אין ספק שביצועים הם הדאגה העיקרית עבור Notepad++, מכיוון שזו הסיבה לעצם קיומו. אבל גם גודלו הקטן והתכונות הגנריות העשירות שלו חשובים מאוד. הודות לבקשות התכונות של המשתמשים, Notepad++ הפך לא רק לעורך קוד מקור גנרי, אלא גם לעורך טקסט רב-תכליתי מלא.
איך הייתה ההשקה עבורך?
ההשקה של פרויקט Notepad++ הייתה באמת די רגילה. מעולם לא חשבתי ש-Notepad++ יהפוך לפופולרי. שמתי גם את קוד המקור וגם את הקבצים הבינאריים ב-SourceForge, ואז המשתמשים הורידו אותו והשתמשו בו. קבלת משוב ממשתמשים היה דבר טוב (ותמיד כך).
איך מטפלים ביעילות בבקשות וביקורות של משתמשים?
טיפול בדוחות באג קריסה הוא תמיד בראש סדר העדיפויות, שלדעתי ברור לכל מנהל פרויקט.
עם זאת, לגבי בקשות התכונה, אני לא מגיב אליהן מיד. אם אותן בקשות תכונה ימשיכו להגיע, אז אשקול ליישם אותן.
למרות שאני ממעטת להשיב לביקורות של משתמשים, אני מקשיב להם. אני מתאים את כיוון הפרויקט אם הביקורות מספיק בונות והוגנות; אחרת, התפקיד שלי הוא לשקול מה טוב לפרויקט (עם החזון שלי שעשוי להיות סובייקטיבי), ואני יכול פשוט לעזוב אותם.
עכשיו, איך מחלקים זמן בין פיתוח פיצ'רים חדשים לניהול קיימים?
ארכיטקטורת הקוד של Notepad++ אולי לא העיצוב הטוב ביותר מבין פרויקטי תוכנה, אבל היא מספיק טובה וישירה לתחזוקה. הוספת תכונות חדשות לא משפיעה בדרך כלל על קוד ישן.
מצד שני, אני צריך לפצל זמן בין קידוד וניהול של בעיות הקשורות לפרויקט. דוגמה אחת היא בניית אתר מסמכים מקוון המאפשר לאנשים לשתף פעולה.
איזו עצה היית נותן לאחרים שרוצים לקחת על עצמם פרויקט דומה?
"תהנה" היא המטרה הראשונה והעיקרית. אין צורך להסביר מדוע פעולה זו תביא לפרויקט שלך הרבה אלמנטים טובים.
"להפוך את זה כמה שיותר פתוח" היא המטרה העיקרית עבורי להגיע לפרויקט פופולרי. אף אחד לא יכול לבנות קתדרלה לבד.
מאחורי האפליקציהנותן מבט מבפנים כיצד נוצרו כמה מהאפליקציות האהובות עלינו - מהרעיון ועד ההשקה (ומעבר לכך). יש מישהו שהיית רוצה לראות מוצג? אֶלֶקטרוֹנִיאנדי.
